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ABSTRACT 


The goal of the research was to investigate the design of 
code generators which are relatively mac h i ne-ind ep end ent. 
Two complementary approaches were investigated. In the 
first approach software design techniques were used to 
design the structure of a code generator for Halmat. The 
major result of this research was the development of an 
intermediate code form known as 7UP. The second approach 
viewed the problem as one in providing a tool to the code 
generator programmer. The major result of this 
investigation was the development of a non-procedural* 
problem oriented language known as CGGL <Code Generator 
Generator Language). 



1. INTRODUCTION 


This is a final report on the grant entitled "The. Design 
of Relatively Machine-Independent Code Generators" conducted, 
under contract to NASA Langley Research Center under 

contract NAS1-14972» task order 14. 

A compiler for a programming language can be logically 
divided into the folloiuing phases: scanner^ parser/ code 

improver (or optimizer)/ and code generator. In the last 20 
years a great deal of research has been expended on- the 
first 3 phases/ uihile little work has been done on the last 
phase. The design and imp! ementati oh of code generators is 
widely thought to be an erroi — prone/ expensive/ highly 
machine-dependent task. 

The goal of this research was to investigate the design 
of code generators which are relatively machine-independent. 
Specifically this means that for two machines with si.milar 
architectures <e. g./ one-address with indexing and a single 
accumulator)/ large portions of the code generator would 
remain the same. Two separate but complementary approaches 
to this problem were investigated with fruitful results. 

In the first approach software design techniques were 
used to design and iteratively improve the design of a code, 
generator from the intermediate code HALMAT (for the 
language HAL/S <1975>) to the Intel 8030. The major result 
of this approach was the design of an intermediate code form 
known as 7UP. This design was implemented under separate 
contract by NASA to Computer Sciences Corp. (contract 
NASl-14900). This work is described in the next section. 

The second approach viewed the problem as one of 

providing a tool to the programmer who implements a code 
generator. The major result in this area was the 
development of a non-procedural/ problem-oriented 

programming language known as CGGL (Code Generator Generator 
Language). An 8080 code generator was coded in CGGL and 
compared to the 7UP implementation. This research is 
discussed inthethird section. 
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2. 7UP 


In this part of the research various software 
methodologies were to be used in the design of a 
generator for the subset of HAL/S given in Figure 
Specifically the techniques of Jackson <1975> and 
hierarchical machine design <Dijkstra> 1972; 
were combined to produce an initial design. 


HAL/S 


integer constants 
integer variables 
integer expressions 
subscripted variables 

=/ +• — 

indexing 

=1 >i >=i <, <= 


GO TO 
labels 

IF . . . 

THEN . . . 
ELSE . . . 


DO WHILE 


DO UNTIL 


Figure 

design is shown in Figure 2. 

This designwas 
Computer Sciences 
code form and 
implementation 


design 
code 
1 . 
of 

Mills, 1971> 
This initial 


HALMAT Op erators 


operand tag LIT 
operand tag SYT 
operand tag VAC 
operand tag SREF 

lASN, I ADD, ISUB 

DSUB 

lEQU, INEQ, IGT, INGT, 
ILT, INLT 


BRA 

LBL 

IFHD (IF header) 

FBRA (branch to ELSE) 

BRA (branch to end IF) 

LBL (ELSE label ) 

LBL (end IF label ) 

DTST (DO WHILE header) 

CTSTW (DO WHILE condition end) 
ETST (DO WHILE end ) 

DTST (DO UNTIL header) 

CTSTU (DO UNTIL condition end) 
ETST (DO UNTIL end) 


Subset 


implemented (under contract NASl-14900 to. 
Corp. ) using HALMAT as the intermed i.at.e ^ 
the Intel 8030 as the target machine. This 
(in Pascal) was subject to a modularity 


1; HAL/S 
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analysis <Myersi 1975>j the results of this analysis are 
summarized in Figure 3. Note that the term class in Figure 
3 refers to a group of related modules. The code generator 
itself consists of approximately 40 routines. 

In analyzing the module calling tree of this 
imp lementat i onj several problems became evident. The most 
serious of these was the lack of clear separation of levels^ 
depicted in Figure 3 as classes 4 and 6 (accumulator 
management and IC generator). It was apparent that the 
internal code generated within the code generator should be 
made explicit. 

Emphasis now shifted to the design of this internal code# 
which was named 7UP (or sometimes HAL/P). This internal 
code was to be closer to machine language than HALMAT and 
was to include accumulator management but not explicit 
addressing (that is, other than symbolic addressing). 7UP 
evolved into a hypothetical* one-address* single-accumulator 
machine. The operators and operands for this machine are 
shown in Figures 4 and 5. 

The 7UP machine was analyzed and a number of 
recommendations were made. Some of these were aimed at 
eliminating redundant operations* while others were aimed at 
allowing as much local optimization as possible to be done 
in the HALMAT-to-7UP translation as possible. (Note that 
these recommendations were not implemented as of the date of 
this report). These revised 7UP operators are given in 
Figure 6. 

The design goal for 7UP was to put as much of the work 
and local optimization as- possible into the HALMAT-to-7UP 
translation and as little as possible into the 7UP-to- 
mach ine-lang uag e translation. The implementation was 
revised to explicitly generate and use 7UP. Although this 
implementation was not retargeted for a machine other than 
the Intel 8080* it was still felt that the goals were 
largely achieved. A modularity analysis of the revised 
implementation is given in Figure 7. 

The goal of doing local optimization in the translation 
to 7UP was clearly perceived to make this translation ever 
more complex. It was desired to develop some form of tool 
to simplify this task. A programming language approach was 
adopted for this problem and the result of this research was 
the development of the language CGGL* which is described in 
the next section. 



HALMAT 


Level 1 



Binary Relocatable Code 


Deals with instructions 
necessary to handle a 
specific HALMAT operation. 


Only level to know how m.any 
accumulators there are. , 
Stores into temporaries as 
needed. 


Only level to deal with 
operand addressing. Knows 
about actual machine 
instructions. 


Only level to know instruc- 
tion format. Resolves 
forward references. 


Figure 1; Preliminary Design of a Code 
Generator for INTEL 8080. 






- 6 - 









Figure 3: Fan Out of Module Classes 
Code Generator (v. 1) 
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Notation; 

ACC = accumulator 

EA = effective address (see Table 2) 
PC = program counter 
C(...) = contents of ... 


jcode 

Mneumonic 

0 

STORE 

1 

LOAD 

2 

HALT 

3 

JUMP 

4 

JFALSE 

5 

JTRUE 

6 

CALL 

7 

RETURN 

8 

ADD 

9 

SUB 

10 

MULT 

11 

CNEQ 

12 

CEQ 

13 

CNGT 

14 

CGT 

15 

CITLT 

16 

CLT 

17 

INIT 

18 

SUBSCR 

19 

lo.ad_imd 

20 

ADD_IMD 

21 

SA\‘E ADDR 

22 

ST0RE_TE.'-!?. 

23 

GEN LABEL 


Interpretation / - ■ 

C(ACC) C(EA) 

C(EA) -»■ C(ACC) 

HAL/P machine halts • 

EA C(PC) 

i^ C(ACC) = false then EA -> C(PC) 
if C(ACC) = true then EA -> C(PC) 
subroutine call 
return from a subroutine 
C(ACC) + C(EA) C(ACC) 

C(ACC) -.C(EA) C(ACC) 

G(ACC) * C(EA) ->• C(ACC) 

(if C(ACC) V C(EA) then true else false ) 

(if C(ACC) = C(EA)' then true else false ) 

(if C(ACC) <- C (EA) then true else false) - 
(if C(ACC) > C(EA) then true else false) .-»• 
(if C(ACC) >= C(EA) then true else false ) 
(if C(ACC) < C(EA) then true else false ) 
program. initialization . - I. 

C(ACC) + EA C(ACC) 

EA C(ACG) 

C(ACC) + EA -> CfACC) 

C(ACC) are saved in an address temporary 
CCACC) C(TEMP) 

associate the PC with the address field 


Figure 4 : impiemented 7up Operations ' 


C(ACC) 

C(ACC) 

C'(ACC) 

C(ACC) 

- C(ACC) 
C(ACC) . 
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Tag Code 

Mneumonic 

Interpretation 

1 

. SYT 

Effective address determined by 8080 translatb.rs 

2 

INL 

Internal label! addres$ determined by LABEL 
operation 

3 

VAC 

Temporary 

4 

XPT 


5 

LIT 

Literal:.. 8080 can use immediate instructions,/ 

6 

BID .. 

■ Immediate: ; operand .number is a constant 

7 

AST 


8 

csz 

• • . V' — ... ‘ V. ^ ' 

9 

ASZ 


10 

OFF : . 


11 

SREF 

. Other than in a SA\’E_ADDR operation ind±cates:-a 
;■ subscripted reference^ ' . 

15 

XREF ' : 

Address' of ah external ^procedure : - 


Figure' :5 : 7up Operand : Tags. ; 



Notation: 

ACC = accumulator 

EA = effective address (see Table 2) 
PC = program counter 
C(...) = contents of ... 


Opcode Mneumouic • ■ Interpretation ^ - . • . : : 

0 STORE C(ACC) -> C(EA) . 

1 LOAD C(EA) C(ACC) 

2 HALT HAL/P machine halts ' 'v : V 

3 ^ JUMP . ; .EA -> C(PC) ; , ■ V ' ^ 

4 JFALSE . C(ACC) = false then EA -C(PC) 

5 JTRUE if C (ACC) = true - then EA C(PC) , -h 

6 CALL subroutine call. ; 

7 RETURII return from a' subroutine-, . 

8 ADD , C(ACC) + C(EA) C(ACC) ^ ^ , 

9 SUB C(ACC) - C(EA) :*>; C(ACC) • , . • A '. - 

10 MULT C(ACe) * C(EA) C(ACC) 

11 CNEQ • (If C (ACC) i C(EA) then true ; else false ) -*• C (ACC) .. 

12 CEQ (if C(ACC) '= C(EA) then true else f alse ) C (ACC) ' 

13 GNGT (if C(ACC) <-: C(EA) then true else . false > -» C (ACC) 

14 CGT , (if C(ACC) > C(EA) then true else false ) C(ACC) 

15 CNLT (i^ C(ACe) >= C(EA) then true else ; false) -» C(ACC) 

16 CLT (_^C(ACC)< C(EA) then true else false ) -»C (ACC) 

17 INIT program initialization : . , ; 

18 . SUBSGR : C(ACC)’ + EA ->■ C(ACC) 

19 SAVE ADDR C (ACC) are saved in an address temporary 

20 LABEL associate the PC with the address^ field 

21 PROC • associate- the; PC with the address field _ 

Generate code to save the return address . . 

• 22 INCR C(EA) + C(ACC) C(EA) ■ ^ 

13 DECR; , ■ ■ : C (EA)- -■ C(ACC) ,C (EA;) ■ ' , ' ; ; ^ f 

24 • CONST indicates conpile-tine,' address calculation • . 

Figure 6: Revised 7up Operations 
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Figure 7: Fanout of Module Classes 

(7up A'ersron) 












































3. A CODE GENERATOR GENERATOR LANGUAGE 


CGGL (pronounced sea-gull) is a non-proc edura 1 # problom- 
oriented language for writing code generators for compilers. 
The output from a CGGL compilation is a high-level language 
(in our case Pascal) program for generating machine code. 
CGGL is based on the work of Donegan <1973>. 

Thus* CGGL is a language in which to express a program 
from which a code generator (CG) can be produced. The input 
to the latter is binary trees and the output machine or 
assembly code. In order to remain independent of the exact 
form of both the intermediate code (IC) and of the machine 
language! CGGL is used to generate only a portion (the 
Translate routine) of the actual code generator/ as 
illustrated in Figure 8. The remaining routines must be 


Code Generator 


Intermediate Code 

in CGGL 

1 

1 

1 


1 

1 

1 

1 

t 

1 

1 


1 

Tree Build/Input ! 

! » 

! CGGL 

Pascal 

! 1 

1 Comp i 1 er 


Translate i 

t 1 



1 1 

IC Dependent Routines ! 

i 1 

ML Dependent Routines 1 

1 

■ . 1 


I ■ 

I ■ 

I 

V 

Machine Language 
Figure 8; Role of CGGL in Code Generation 


coded by hand in the CG language (in our case/ Pascal ) . 

A description of the language CGGL is given in Appendix 
A. The language itself can be used in a variety of ways. 
For example! it could be used to translate from HALMAT to 
7UP and from 7UP to machine code. As an experiment it was 
decided to translate HALMAT ■ d i re c tl.y to 8030 machine code 
using CGGL. This, code generator is given in Append.ix’ C. • 
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As a point of comparisoni it was decided to compare the 
quality of code generated in the 7UP implementation versus 
the CGGL implementation. (Note at that time no CGGL 
compiler existed). CGGL generated code which used 
considerably less time and space than 7UP. These results 
are given in Figure 9. It should be noted that at the time 
the 7UP implementation was done* the quality of code was not 
a consideration! only the speed with which the 


7UP CGGL 

HAL/SDu tesCu c 1 e sBu tesCu cl es 
X = 1 834 520 
X = X + 1 12 51 833 
X = X + yl2 511043 
... X - (y + 2 ) . . . 281191251 
IF X = y + 1 THEN351381247 
x$(3) = 0221041148 
X = y$(i - 1)582501672 


Figure 9: Comparison of 7UP and CGGL 

implementation could be comp 1 eted. 

In addition the CGGL implementation was considerably 
faster to code and easier to modify. One indication of this 
was the ease with which subscripting (indexing) was added. 
In the 7UP implementation this caused considerable problems! 
since the 8080 lacks true index registers. The basic 
addressing mechanism had to be substantial ly changed as well 
as the accumulator management routines. However! in the 
CGGL implementation only one new operation (DSUB itself)! 
two new states were added to condition AROPi three new 
transitions were added to trans i t i on AROPi and three new 
terminal configurations to operation lASN. Unlike the 7UP 

implementation! substantial changes to previous work was not 
required. Thus# for assignments or expressions, not 

involving indexing! the same code is generated as previously 
(that iS! before the addition of subscripting). ..In, 

addition! unlike 7UP 16-bit temporaries were not introduced. 

Another example of the ease with which a CGGL program can 
be modified was the introduction of immediate instructions. 
This change involved modifying one transition and adding two 
terminal configurations. 

In c one 1 us i oni implementing a HALMAT (or any other IC) 
code generator in CGGL is quite stra ightf orward for a single 
accumulator machine. CGGL is best at expressing the complex 
case analysis required to generate good . local code. 
Experience (admittedly limited) has shown that code 
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generators expressed in CGGL are easily modifiable to add 
new operators, to improve the code generated, and to fix 
bugs. 


4. CONCLUSIONS 


The research into the application of software design 
methodologies to the design of code generators took some 
surprising directions. Af t.e r an initial design had been 
implemented* a modularity analysis showed problems in the 
design. This lead to the development of an internal form 
called 7UP which is closer to machine language than HALMAT. 
This internal form is expected to decrease the effort 
necesssary to retarget a HAL/S compiler. 

As the investigation into implementing a larger subset of 
HAL proceeded* it became clear that the code generator would 
become not only larger* but also more complex. The 
investigation lead to the development of the non-procedural 
language CGGL. 

A code generator for the Intel 8080 was written in this 
new language. However* the code generator could not be 
tested because of the lack of a CGGL compiler. Preliminary 
experience indicates that CGGL may have a revolutionary 
impact on the development of code generators. 
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APPENDIX A: CGGL 


A GGGL program consists of conditions* variables* 
transitions* conflicts* operations* and procedures. The 
elements of a CGGL program can be arranged in ang convenient 
order* although the compiler mag insist on a specific order. 
A complete grammar for CGGL is given in Appendix B. 

The input to the code generator generated is, assumed to 
be an IC tree consisting of operators and operands (end 
nodes). The exact description of a node is independent of 
CGGL. ■ 

A condition statement specifies a named class of states 
uhich an operand can take on. For example: 

. condition AROP = input LIT* VAC* SYT 
internal INACC* I NR EG* ONSTACK; 
sags that an operand of tgpe LIT* VAC* or SYT belongs to the 
class AROP. In addition* three internal states are defined. 
All of these states are mutuallg exclusive* i. e. * the 
operand can be in at most one of them. The condition 
statement 

condition FLOW = input • I NL* 

sags that an operand of tgpe INL belongs to the class FLOW* 
this class has no other input or internal states. States 
are used in CGGL to keep track of the status of a given 
operand* for example* whether an operand is in the 

accumulator INACC. 

Variables in CGGL are used to pass information down the 
tree. Such variables mag be used to control decisions in 
both transitions and operations. For example: 

v^ CMP_NODE = (ASSIGN_CMP* JMP_T* JMP_F); 
declares a variable with three possible values; one of these 
ASSIGN_CMP is its initial value. One method of changing the 
value of a variable is bg means of the let statement* which 
can be used onlg within an operation. For example* 
c ons i d er : 

condition FDR A (FLOW* AROP); 
let CMP_mode = JMP,_F,; ... 

On entrg to this operation* the current value of CMP_NODE is 
saved and is then-replaced bg the value JMP_F; just before 
exit* the old value is restored. The values of variables 
can also be changed bg transitions* as will be seen. 

A transition statement defines all of the state changes 
which can occur on a given* named condition. A state change 
X -> Y specifies how an operand moves from an input or 
internal state X to an internal state Y. For example* 

consider: 

trans i t i on AROP; , ' 

LIT -> INACC: GEN2(MVI A, #); 
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This transition specifies what code is required to move a 
literal into the accumulator for an INTEL 8080. The symbol 
# stands for the operand in question. GEN2 is a call on a 

Pascal routine for generating 2 byte instructions for the 
INTEL 8080. Thus, transitions associate (Pascal) code to be 
generated with state changes on operands. 

Since certain operations, e. g. indexing on the 8080. may 
also require the use of the accumulator. COOL allows the 
explicit statement of conflicting states for pairs of 
operands, for example: 

conflict ARQP. ARDPi 
INACC. INACCi 

The above example states that if you have one operand in the 
accumulator. it is incorrect to put the other operand into 
the accumulator. All such conflicts are assumed to be 

commutative. Note that the pair ONSTACK. ONSTACK is not a 
conflict. 

Another. more subtle way of specifying conflicts is 
through the use of variables and transitions. Consider the 
following: 

vaji ACC_STATUS = (ACC_FREE. ACC_BUSY)i 
trans i t i o n AROP using ACC_STATUS; 

LIT. ACC_FREE -> INACC. ACC_BUSY: GEN2(MVI_A. #); 
This specifies that if one wants to load a literal into the 
accumulator. the value of ACC_STATUS must be checked and if 
necessary. the accumulator freed (by means of another 
transition). Although unnecessary for the single 

accumulator machine. such an approach appears necessary for 
multiple accumulators in order to prevent an explosion of 
states. 

An operation specifies for each operator the number of 
arguments and condition class of each argument and the 
internal state (if any) computed by the operation. The 
operation lists terminal configurations and their associated 
code generator statements. Possible transitions are 
entirely determined by the transitions given for each 
condition class and by the terminal states allowed. For 
examp 1 e: 

ooerat i on I ADD (AROP. AROP) returns AROP; 

INACC. ADDR_LOADED -> INACC: GEN1(ADD_M); 
ADDR_LOADED. INACC -> INACC : GENl ( ADD_M ) ; 
specifies that lADD has two operands of condition class 
AROP. leaves its result in the ACC (state INACC). and 
requires that one of its arguments be INACC and the other be 
ADDR_LOADED. The operation I ADD is easily seen to be 
commutative. Like transitions. operations may also use 
global variables, as for example: 

operation IEQU(AROP. AROP) using CMP_f10DE returns 
AROP; 

INACC. ADDR_LOADED. . JfiP_T -> INACC: 

GENl (CMP M). GEN3(JZ. JMP TARGET); 
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It should be noted that the returns clause as well as its 
associated state on the right-hand-side of an -> if entirely 
redundant. This information has already been specified in a 
transition . 

A procedure specifies a group of statements. It is 
useful for specifying long seq.uences of code. A procedure 
call is specified by a call <proc name>. An example of a 
procedure is the following: 
proc CMP_EQ» 

GEN2(MVI A/ ONE) I GEN3<JZ/ PC+4). GENKZAOi 



<CGGL program> 
<statement list> 

<statement> 

<var decl> 

<c ond i t i on> 
<internal part> 

<trans i t i on> 

<c6nf 1 ict> 
<coTvPlict list> 

<op erat i on> 

<assign list> 
<as s i g n> 

<proc> 

<using part> 
<returns part> 

<test set> 
<test> 

<result> 

<PL cod e> 

<list> 


APPENDIX B: CGGL SYNTAX 


; : = <statement 1 i st> eojP 

<statefneTvt list^ <C5tatefneTrt^ i 
<statement> 

;;= <var decl> 1 <condition> ! 
<transition> I <conflict> I 
<operation> ' <p'roc> 

: : = vaT ■Cidl>' = ( ■Oi st^ ) j . 


: ; = condition <id> = input <1 ist> 
<ihternal part> » 

; : = internal <list> ! e 


; ; = trans i t i on <ClistI> fusing part^ / 
<test set> end tr j 


: := conflict <conflict list> end c o ; 

: : = <conf l.ict list> <list> ; i <list> 


; ;= OP erat i on 'Cid!> ( ■Clistl> ) 

<using part> <return part> i 
<assign list> <test set> end op_ 


::= <assign list> <as5ign> ! e 
; •= let <id> = <Cid> » 


; := D r o c ■Cidl> * ^PL codeia » end p r ; 


::= using <list> I e 
; = returns < i d> I e 


::= <test set> <test> I <test> 
;:= <list> <result> : <PL code> ; 

: : = <1 ist> ! e 


; ; = ' <text> ' 


; : = <1 ist> . <id> I <id> 
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Remarks 


1. An <id> can be composed of letters* digits* and 
underscores* the first of uihich must be a letter. 

2. A comment may occur anyuhero a blank may occur and is 
defined as; 

<comment> ::= (* <text> *) 

3. Certain characters in the reference language require 
special treatment in the implementation. All underlined 
words such as var are reserved. 

4. # in <text> is replaced by the operand name OP. 
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OPERATION ISUB(AROPi AROP ) RETURNS AROPi 
IN_ACC. LIT -> IN_ACC: 'GEN2(SUB_I, #2)'; 

IN_ACC, ADDR_LOADED -> IN_ACC; 'GENl <SUB_M> 

IN_ACC, IN_REG -> IN_ACC: 'GENl ( SUB_C ) ' ; 

END_OPi 

OPERATION DSUB(AROP, AROP) RETURNS AROP; 

SYT, IN_ACC -> IN_ACC: 'GENl < MDV_C_A ) ; GEN2(MVI_B, ZERO) 

GEN3(LXI_HL, #1); GENl (DAD_BC ) ' ; 

END_OPi 

OPERATION IEQU(AROP, AROP) USING CMP_MODE RETURNS AROP; 
IN_ACCi ADDR_LOADED, JMP_T -> IN_ACC: 

'GENl (CNP_M); 

GEN3(JZ/ JMP_TARGET) '; 

ADDR_LOADED, IN_ACC, JMP_T -> IN_ACC: 

'GENl (CMP_f1); 

GEN3<JZ> UMP_TARGET) '; 

IN_ACC, IN_REG. JNP_T -> IN_ACC: 

'GENl (CMP_C); 

GEN3(JZ, JMP_TARGET) '; 

IN_ACC, ADDR_LDADED, JMP_F -> IN_ACC: 

'GENl (CMP_N); 

GEN3(UNZ, JNP_TARGET) '; 

ADDR_LOADED, IN_ACC, ~JMP_F -> IN_ACC; 

'GEN1(CNP_M); 

GEN3(JNZ, JMP_TARGET) '; 

IN_ACC, IN_REG. JNP_F -> IN_ACC; 

'GENl (Cr-1P_C) ; 

GEN3(JNZ, JMP_TARGET) '; 

END_OP; 

OPERATION IGT(AROP, AROP) USING CNP_MODE RETURNS IN_ACC; 
IN_ACC/ ADDR_LOADED, JMP_T -> IN_ACC: 

'GENl (CMP_M); 

GEN3(JZ, PC+2); 

GEN3(JNC. JMP_TARGET) '; 

IN_REG, IN_ACC, UNP_T -> IN_ACC: 

'GENl (CNP_C); 

GENS (JC, Jr'1P_TARGET) '; 

ADDR_LOADED, IN_ACC, JMP_T -> IN_ACC: 

'GENl (CMP _M); 

GEN3(UC, JMP_TARGET) '; 

IN_ACC, ADDR_LOADED, JMP_F -> IN_ACC: 

'GENl (CMP_M); 

GEN3(JZ, JMP_TARGET); - 
GEN3(JC, JMP_TARGET) '; 

ADDR_LOADED, IN_ACC, JMP_F -> IN_ACC: 

'GENl <CMP_M); 

GEN3(JNC, JMP_TARGET) ': 

IN_REG/ IN_ACC. JMP_F -> IN_ACC: 

'GENl (CMP_C ) i 
GEN3(JNC, UMP_TARGET)'; 

END OP; 
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OPERATION BRA(FLOW) RETURNS FLOW; 

INL -> INL: 'GEN3(JMP, 

END_OP; 

OPERATION LBL(FLDW) RETURNS FLOW; 

INL -> INL; 'SET_ADDR(^H, PC)'; 

END_OP; 

OPERATION IFHD(FLQW) RETURNS FLOW; 

INL -> INL: "i 

END_OP; 

OPERATION DTST<FLOW> .RETURNS FLOW; 

INL “> INL: 'PUSH_DDSTACK<PC, Ul>'i 

END_OP; 

OPERATION ETST(FLOW) RETURNS FLOW; 

INL -> INL: 'POP_DDSTACK(OLD_PO; 

GEN3(JMP. OLD_PC)'; 

END_OP; 

OPERATION FBRA(FLOW, AROP) RETURNS FLOW; 

LET CMP_MODE = JMP_F; 

INL, VAC-> INL: 'BLD_HALMAT( JMP_TARGET, #1 > ; 

TRANSLATE ( #2 ) '; 

END_OP; 

OPERATION CTSTW(AROP) RETURNS FLOW; 

LET CMP_MODE = JNP_F; 

VAC -> INL; 'TOP_DOSTACK(UMP_TARGET>; 
TRANSLATE ( #1 ) '; 

END_OP; 

OPERATION CTSTU<AROP) RETURNS FLOW; 

LET CNP_NODE = JMP_T: 

VAC -> INL; 'TCP_DOSTACK(UriP_TARGET); 
TRANSLATE < 1 ) '; 

END_OP; 
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